1. Field of the Invention
The present invention relates to a multiple printer and associated print environment contained within a local, networked, or remote computing environment. Specifically, the present invention relates to a computer-based printing system having the ability to match a print job contained on one or more printing sources to the “best-fit” printing device contained within a set of available printing devices, wherein the “best-fit” is based on a set of identified criteria.
2. Background and Related Art
With the emergence of software and hardware components of computer systems, users are able to employ the systems to perform a variety of tasks. For example, a user may utilize a software application, such as a word processing, spreadsheet, or other application, to create a file or document. Once created, the document may be printed on a local, network or remote printer device.
In a computer system that includes simply a client computing device and a printing device, such as a printer, printing is significantly less complicated than printing within a networked environment.
FIG. 3 is a general depiction of a traditional client-based printing system, wherein all print jobs are directed to a local or remote printing device. In this basic setup, the User is unconcerned with selecting from a plurality of printers or printing devices because the system simply has only one printer accessible from client computing device. Upon selecting the Print command from an application or background process on the client computing device, the print job is automatically directed to the only printer attached to the system. Printer characteristics, such as speed, quality, etc. do not matter as no other available options for printing exist.
Specifically, FIG. 3 features a traditional print system comprising a client computing device 84 capable of supporting and running an application program 88 or a background process (not shown) from which a user may initiate a print job. The client computing device has contained thereon a print driver 92, a spooling device 96, a print processor 100, and a port manager 104. Once a print job is initiated, it is sent to the print driver 92, which then despools the data to the spooling device 96. Spooling device 96 subsequently despools the print data to printing device 134 through the appropriate port as directed and controlled by port manager 104. Optionally, a print processor 100 may be used to process the print job and send the appropriate print data to printing device 134.
In a computer system that includes various client computer devices and a printer device connected over a network, the utilization of the networked system to print a file or document traditionally includes the use of print queues on a centralized computing device that is commonly referred to as a print server. A print queue lines up print jobs for a particular network printer device. Thus, for example, when a number of documents are to be printed by a network printer, the documents are ordered in a print queue on the print server and pulled one at a time off the queue for printing. Print jobs are commonly executed in the same order that they were placed on the print queue, but may be prioritized based on other criteria, such as by the size or type of the documents to be printed.
When a user initiates a print command at one of the client computer devices, the client de-spools print data for the print job to a print queue that is associated with a corresponding network printer. The print queue is located on a print server. When it is time to remove the print job from the queue, the print server de-spools the print data from the print queue to the network printer. While this method for network printing enables a variety of client computer devices to utilize a network printer device, the method requires a large amount of network traffic since the print data must be de-spooled twice over the network, once to the printer server from the printing source, and once to the printing device(s) from the printer server. Furthermore, the traditional method causes a loss of bi-directional communication, resulting in a loss of error handling and/or a loss of job completion notices. Moreover, the traditional method requires the use of an additional computer device (the print server), which causes an increase in hardware costs and maintenance.
FIG. 4 is a general depiction of a client/server-based printing system, wherein all print jobs are directed to a printing device contained on a network. This setup represents a more complicated layout than the one previously described, as one or a plurality of printers may be accessible from one or more client computing devices. It is in this layout that most printing systems are setup and in which a majority of the problems described above are realized.
Specifically, FIG. 4 features a traditional print server printing system comprising a client computing device 184 in communication with a print server 206. Client computing device 184 functions much the same way as described in FIG. 3, only that print server 206 is capable of processing multiple print jobs from multiple client computing devices, each of which are in communication with or connected to print server 206, and sending these print jobs to one or more printing devices 234. As described above, a print job is initiated from application 188 (or a background process) and sent to print driver 192. A print job typically comprises print data in the form of raw or EMF data. Once the print job is sent to print driver 192, print driver 192 forwards the information on to spooling device 196. Spooling device 196 subsequently despools the print data to port manager 208. A print processor 200 may optionally employed to process the print job in which case print processor 200 sends EMF data to printer driver 192, and raw data to port manager 208. In each case, all of the necessary print job information is provided to port manager 208. Once received, port manager 208 sends the information out of client computing device 184 to a print queue 212 located on print server 206.
Print server 206 comprises a print driver 220, spooling device 216, and optionally print processor 200 of its own. Unlike the client-based print system described above in FIG. 3, the server-based system handles the processing and printing of the print job. Port manager 204 is also located on print server 206 and serves to direct the print job to the one or more printing devices 234, as appropriate.
Some methods and systems have attempted to solve the problems of network printing through direct peer-to-peer de-spooling of print data from the client to the printing device. In these methods, the print provider on the client opens a connection to the network printer through the use of a particular protocol, such as TCP/IP, Novell Netware, or Apple Talk, and attempts to spool data directly to the printer. However, since the network printer can be shared by a variety of clients, the printer must serialize the spooling and printing of print jobs that arrive simultaneously. Typically, the printer blocks subsequent attempts to de-spool and print a print job while another print job is being printed. Alternatively, the one print job is de-spooled into firmware memory or onto a disk drive while another print job is being printed. These methods cause the client computer device to consume CPU cycles and/or generate additional network traffic. Furthermore, there is no centralized management of the print jobs and thus no prioritization.
One attempt to reduce the amount of network traffic required in performing network printing operations includes providing an operating system on the client computing device that allows or facilitates journaled data to be de-spooled to the print queue rather than the actual print data. The amount of journaled data is assumed to be less in comparison to the amount of traditional print data. Therefore, the amount of network traffic is reduced. However, this attempt requires a copy of the corresponding printer driver to be located on the print server, further requiring the maintenance and/or licensing of an extra printer driver. Moreover, this attempt does not address the loss of bi-directional communication or the requirement of an additional computer device, the print server. Moreover, the print server consumes additional CPU cycles to render the journal data into printer ready data.
In traditional systems, a user manually selects a printer driver/printer from those available on the client computing device or printing source, and examines the status of the printer from the printer status monitor. For example, within the Microsoft family of Operating Systems, a User generally initiates a print job from an application by pulling down the File Menu and selecting Print, or by selecting a file and choosing the print command option from a list of options available by right clicking on a file or folder. The Print selection subsequently displays a dialog to the User, wherein the dialog contains a pull-down list of available printers installed and accessible from the client computing device or printing source. While allowing some degree of flexibility, this type of limited process and/or approach suffers in that the User must either have prior knowledge of the capabilities of each printer accessible from the client computing device prior to making any final determination or selection of printers, or alternatively, the User must manually select and examine (i.e., enumerate) each printer selection to determine each respective printer's capabilities and print quality. In addition, to determine the status of each printer, or a desired subset of printers, the User must invoke the printer status monitor on each accessible printer. This approach additionally suffers in that the status monitor only provides very limited information, often only the number of print jobs queued or OFFLINE/READY. No other information is relegated to the User, such as the size of each print job queued or reason a printer is OFFLINE, that would or could be advantageous in making a suitable printer selection. Still further, this approach suffers in that the printer driver and status monitor provide no information on the speed (i.e., PPM), or locality (i.e., physical location) of the respective attached printing device(s).
U.S. Pat. No. 6,088,120 to Shibusawa et al., titled “Printer Managing Apparatus, Printer System and Printer Setting Method” (the '120 patent) attempts to solve some of the above-described problems. The '120 patent discloses a virtual printer driver that is the conjunction (AND) or disjunction (OR) of the printer capabilities of a predefined set of printers. However, this approach suffers in that the invention does not take into account the availability or locality of the printers. Moreover, the invention suffers in that it requires the printers to be network printers, and managed by a printer server.
The '120 patent also suffers in that the printer capabilities are predetermined, which, as a result, requires each of the printers to be pre-known to the User prior to choosing a printer and when constructing a Virtual Printer Driver. As such, the User must manually reconstruct the virtual printer driver if any one of the printers' capabilities changes, becomes unavailable, or a printer is added to/deleted from the list. Since the printers have to be pre-known, the User is unable take advantage of any “auto-discovery” techniques to dynamically find or select new and existing printers, or make changes in a printers' capabilities, such as modifying sheet assembly characteristics and/or finishing options, etc.
Still further, the '120 patent also suffers in that the disclosed Virtual Printer Driver cannot take advantage of any Print Assist programs that are, or may be inserted, into the print data flow, such as a custom print processor.